1. Field of the Invention
The present invention relates to the field of software development and, in particular, to service-oriented programming and transactional support for nested composite software services.
2. Description of the Related Art
The reliable and correct execution of composite Web services is a key concern in the implementation of the emerging service-oriented systems. Addressing the reliability and correctness of nested composite Web services at runtime requires the addition of fault tolerance and transactional support to service-oriented platforms. Unfortunately, none of the known transaction processing technologies provides a model suitable and sufficient for the emerging service-oriented paradigm. This is mainly due to the diverse transactional behavior of heterogeneous and distributed Web service implementations.
The four main categories of existing transaction processing technologies address specific and limited semantic spaces:
Database transactions: This model involves transaction-processing technologies under full control of Data Base Management Systems (DBMS). These technologies assume a homogenous semantic space and dataset definition, based on relational database concepts, and thus are too rigid in definition. Furthermore, the transaction manager is non-extensible and closed to other transaction processing models.
Distributed Object transactions such as CORBA's Object Transaction Service (OTS) and X/Open DTP. Here, objects are only characterized by their interface and the transaction manager does not address the persistence of state. This means that the participating object (or the resource manager) must guarantee recoverability and durability by itself. Once the object provides the required interfaces and follows the specified Two-Phase-Commit (2PC) protocol, it can be used as part of transactions. While this provides a perfect heterogeneous model for automating atomic Web services used within the definition of composite Web services, it is demonstrably insufficient in addressing the transactional support of composite Web services for two main reasons: 1) The service-oriented platform that supports the implementation of composite Web services and provides transaction management capabilities must directly address the persistence and recovery of composite Web services. This is outside the semantic space for OTS and DTP. 2) The semantic space implied by these models strictly requires commit/rollback confirmation. This does not provide any flexibility in defining transactional composite Web services that may need to contain one or more Web services with optional, compensating, or alternative transactional behaviors (refer to the next section for an explanation of these behaviors).
Component container-managed transactions (such as Sun's EJB): This model mainly follows the distributed object model above and thus suffers from the same limitations with respect to the semantic needs of composite Web services. A point worthy of mention is that this model, unlike the distributed object transaction model, uses declarative transaction management. This effectively simplifies the coding of transactions since it only requires setting transactional attributes to adjust a component's behavioral operations. This technique is inspiring in that it separates transaction behavior from business logic, thus allowing reusability. However, it is limited in that it does not provide a way for the external client to override these internal attributes.
Message-oriented transactions and transactional publish/subscribe: These transactions group a set of messages, a unit of work, with strict “all-or-nothing” semantics without addressing data processing and the consistency of data transmissions. This transaction model, like the others mentioned, does not provide semantics that address nested, heterogeneous transactions.
Undoubtedly, the definition of a new semantic space is required for adding reliability and correctness to nested composite Web services. Intuitively speaking, the new semantic space must blend ideas from various existing models to provide the flexibility required for accommodating behavioral diversity demanded by composite systems. The present invention is at the forefront of defining this new semantic space for composite systems.
As the first step in adding reliability to composite Web services we define the semantics of the Web service dataset, herein below referred to as a service-set, that needs to be persistent for the purpose of state recovery after any failure. A service-set is composed of four distinct, and possibly empty, data-elements: 1) the inputs, 2) the properties (such as the URL of the service), 3) the outputs, and 4) the composite-set, where the composite-set is either the empty dataset (in the case of atomic Web services), or a set containing one or more service-sets. Note that the recursive definition of the nested-set element allows us to later accommodate recovery of nested composite Web services to any depth.
The recovery of a composite Web service will, at times, require re-execution of embedded services that were successfully executed before the crash. For example, consider a time-sensitive Web service such as GetStockQuote that takes a ticker symbol as input and returns the current value of the stock associated with that ticker as output. Imagine that GetStockQuote is embedded within a composite service that crashes sometime after the execution of the GetStockQuote service. Here, upon recovery, instead of simply restoring the output element of the persistent service-set associated with GetStockQuote, the correct behavior may be to re-execute GetStockQuote to avoid stale and out-of-date data. As a contrary example, consider an IncrementCounterAndGetValue Web service that returns the value of a counter after incrementing it by one. Imagine that this service is embedded in a composite service that crashes sometime after the successful execution of IncrementCounterAndGetValue. Here, unlike in the GetStockQuote example, upon recovery of the parent composite service, IncrementCounterAndGetValue must not be re-executed. Instead, the output of the IncrementCounterAndGetValue instance that was executed prior to the crash must be restored from the output element of the associated service-set. These two contrary examples are intended to demonstrate that not only is the definition of a Web service dataset specific to a service-oriented paradigm, but also the behavior of recovery depends on the application of the service. To address diverse recovery behavior for services, we will introduce a declarative service-set definition where the behavior of recovery can be selected from a finite set of possibilities, decided at the application level, and set as a property on the service-set.
A semantic space for defining the transactional behavior of Web services requires the same type of flexibility as that required for their recovery. It is desirable to define transactional composite Web services without requiring that all embedded services, to any depth, must be transactional services. For example, one may want to define a transactional composite Web service that embeds the non-transactional GetStockQuote service. In other words, the semantic space for transactional Web services must allow for optional, or non-transactional, Web services to be embedded within transactional composite Web services.
Similarly, to accommodate the diverse transactional behavior of heterogeneous Web service implementations, this semantic space must allow for compensation of embedded Web services upon rollback of the parent Web service. For example, upon rollback of a parent composite Web service that embeds a SendEmail Web service, the designer of the parent service must be able to compensate for the already executed SendEmail. In this case, another SendEmail service may be executed to notify the recipient of the cancellation of the first service. Another behavior that must be accommodated in the new space is alternative Web service routing instead of rollback. For example, consider a child ShipThroughFedEx Web service that triggers a failure/rollback upon execution. Here, the designer of the parent service must be able to instruct the transactional system to route to an alternative ShipThroughDHL service instead of rolling back the other prepared services within the parent service.
A flexible semantic space for Web service transactions must also allow combining internal as well as external handling of transactional behavior for Web services. For example, it should be possible to embed a transactional Web service within a composite Web service and then override the rollback behavior of the embedded service to invoke an alternative service, rather than rolling back. For atomic Web services, semantics similar to container-manager, or distributed object transaction model can be leveraged to accommodate automated commit/rollback behavior internal to the atomic Web service.
3. General Background
A software service, or service for short, including but not limited to a Web service, is a discrete software task that has a well-defined interface and may be accessible over the local and/or public computer networks or maybe only available on a single machine. Web services can be published, discovered, described, and accessed using standard-based protocols such as UDDI, WSDL, and SOAP/HTTP.
A software service interface, in concept, represents the inputs and outputs of a black-boxed software service as well as the properties of that service, such as name and location. Take, for example, the interface of a simple software service named GetStockQuote, which retrieves simple stock quote information FIG. 1. This service takes a ticker symbol input and returns the last trade price amount as well as some additional stock quote details, such as the day high and day low. Note that in order to use, or consume, a service, only knowledge of its interface is required. This means that as long as the interface of a service remains the same, different implementations of the service can be swapped in and out without affecting its consumers. This, as well as the fact that a service is a language- and platform-neutral concept, is one of the keys to the flexibility of service-oriented architectures.
An atomic service is a software service that is implemented directly by a segment of software code. In the existing NextAxiom™ HyperService™ Platform, atomic Web services are dispatched via a library. A library is a light, language- and platform-neutral wrapper that is linked to one or more atomic Web service implementations. Atomic Web services are logically indivisible Web services that represent “raw materials” to the HyperService™ platform.
A composite service is a software service that consumes any number of other atomic or composite services. In the HyperService™ platform, a composite Web service is implemented with a metadata-driven model that is automatically interpreted by a high-performance run-time engine.
Visual metadata models, which represent composite software services implementations to the HyperService™ system, are created in a graphical, design-time environment and stored as XML models. This environment offers a new and powerful visual modeling paradigm that can be leveraged to enable the visual modeling of transactional behavior. This environment was specifically designed to enable collaborative, on-the-fly creation of software services by business process analysts or functional experts, who understand the business logic and application required to implement real-world business processes and applications, but have no knowledge of programming paradigms or Web service protocols. FIG. 2 captures the implementation of a composite software service named “FindFiles”.
Any software service that is consumed by a composite service model is said to be “nested” or “embedded” within that composite service. FIG. 3 depicts a hypothetical composite service. This software service is composed of other composite services that can run locally or distributed.